The present invention relates to a firmware trace data acquisition method in communication control processors.
Recently, with the development of microcomputers, many communication control processors are equipped with microcomputers capable of analyzing communicated information and of effecting communication control. It is a general practice to equip a communication control processor with a trace function and with the function of acquiring data traced by firmware (simply referred to as the firmware trace data or the trace data in this specification) when carrying out debugging in a communication control processor or when an abnormality has occurred during an online service and the cause thereof is to be determined.
However, problems have been encountered in that the communication control processor equipped with a trace function has reduced processing power as compared with the communication control processor not so equipped, and in that it is difficult to examine the cause of an abnormality because there has been no distinction between the trace data acquired in a normal operation and those acquired in an abnormal operation. Hence, there is a need for a firmware trace data acquisition method in which the processing power of the communication control processor is not reduced, and which is capable of acquiring, in addition to the trace data acquired in a normal operation, more detailed firmware trace data in the case of an abnormal operation than in the case of a normal operation.
FIG. 1 shows the constitution of a conventional communication control processor comprising a CPU part 80 having a microprocessor mounted therein, and a memory part (hereinafter, referred to as MEM) 81 which stores a program (firmware) for executing communication control processes. The MEM 81 is segmented into a firmware (program) storing part, a work area required when the firmware is being executed, an I/O control area and a trace data storing area which is not included in the communication control processor lacking a trace function. A communication interface part (a communication INF part) 83 is a hardware unit for performing, in accordance with a predetermined communication protocol, communication between a transmitting communication unit and a receiving communication unit that are at the respective ends of a communication circuit. Communication is performed after communication parameters have been set by means of the program.
A DMA (direct memory access) part 82 shown in FIG. 1 transfers communicated data (transmitted data, received data, communication control data etc.) between the communication interface 83 and the MEM 81 by direct memory access which does not involve the program, that is the CPU. Settings are made in the DMA part 82 so that such a transfer can be carried out.
In the communication control processor in which the communication is controlled by means of firmware as shown in FIG. 1, the memory allocation and the process module configuration of the firmware are arranged to incorporate a trace function. Conventionally, the following two types of trace method are employed.
FIGS. 2A and 2B explain conventional trace methods.
FIG. 2A shows a method in which each processing program includes a trace program. It will be noted that a program for a process 1 is composed of a number of steps (STEP 1, STEP 2 . . . ) and that there is provided a trace program at the end of the steps. A process 2 is also composed of steps and a trace program is provided at the end thereof. FIG. 2B shows another method in which individual processing programs do not include a trace program, and a trace program is provided in the form of a trace process call program (noted in the figure as a trace call). The trace process call program is called every time each of the individual processing programs is completed so that a trace process is executed.
FIG. 3 illustrates how data are stored in a conventional trace area (memory area reserved for trace data). In either of the above-mentioned conventional trace methods, the trace program is executed after each process, whereby the trace program places under its control trace items selected by the program from among a number of trace items in the work area of the firmware so as to produce detailed data. The detailed trace data thus obtained are stored in the trace area of the memory. This process of storing the trace data is executed by the CPU 80 by using an appropriate program.
Referring to FIG. 3, when the process 1 is completed, the trace program is activated so that the trace data corresponding to all the selected trace items, that is the trace data 1, the trace data N . . . the trace data N+1 are sequentially stored in the trace area of the memory. The trace data for the process 2, the process 3 . . . are stored in a similar manner each time any of the processes is completed. Since the trace area of the memory occupies a certain predetermined amount of memory (for example, on the order of mKB, i.e. megakilobyte), old trace data are overwritten by new trace data when the trace area has become full.
The aforementioned problems associated with the conventional communication control processor are elaborated upon as follows:
1 The conventional trace is concerned with all the trace items prescribed when the program was originally made. Hence, there is required a relatively long time for the execution of each process because the trace facilities corresponding to all the trace items are activated even when the program is operating normally.
2 When there are a large number of trace items, the time allotted to the execution of communication control processes becomes shorter than the time allotted to trace processes, thereby limiting the ordinary processing performance of the processor to only half of its capability.
3 Since the trace data for all the prescribed trace items are stored in the trace area, irrespective of the (normal or abnormal) condition of operation of the communication control processor, all the detailed data must be sequentially consulted in order to track the cause of any abnormality, thereby reducing the efficiency of inspection to be undertaken in a debugging process or in the case of an abnormality.